home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 102 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB

  1. From: b91926@fsgm01.fnal.gov (David Sachs)
  2. Message-ID: <4e1jfb$1ea@fsgm01.fnal.gov>
  3. X-Original-Date: 22 Jan 1996 21:08:27 -0600
  4. Path: in2.uu.net!bounce-back
  5. Date: 23 Jan 96 03:45:36 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Why no allocator-specific delete?
  9. Organization: FERMILAB, Batavia, IL
  10. References: <4dvid8$460@news.bridge.net> <4e0u1s$5fv@engnews1.Eng.Sun.COM>
  11. Reply-To: sachs@fnal.fnal.gov
  12. X-Newsreader: NN version 6.5.0 #4 (NOV)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMQRaKOEDnX0m9pzZAQHUQQF/dgjskvnZKgm7/fdCYwEy3SwFjWn+fK13
  15.     5GfZNI6NLHucwvj6C8GC8iQKVWKBkYPB
  16.     =dy+z
  17.  
  18. clamage@Eng.Sun.COM (Steve Clamage) writes:
  19.  
  20. >In article 460@news.bridge.net, David Byrden <100101.2547@compuserve.com>
  21. >writes:
  22. >>Why, in the Septenber draft standard, is an allocator-specific verrion of 
  23. >>'new' provided;
  24. >>
  25. >>20.1.4.4
  26. >>
  27. >>           new(x) T    
  28. >>
  29. >>    returns an X::types<T>::pointer, where x is of an 
  30. >>    allocator type X
  31.  
  32. >You are actually referring to the "placement new" syntax not having a
  33. >corresponding "placement delete" syntax.
  34.  
  35. >No good syntax was found for such. The obvious syntax
  36. >    delete (x) p;
  37. >leads to too many ambiguities. More importantly, it means that the
  38. >point of deletion would somehow have to know what placement version
  39. >of "new" was used and what the parameters were. Needing that knowledge
  40. >would make "placement delete" unsafe and hard to use. (Consider the
  41. >general case where the "new" and "delete" expressions are in different
  42. >compilation units, and the parameters to "new" affect how "delete"
  43. >should be called.)
  44.  
  45. >You can define a version of "operator delete()" corresponding to a
  46. >placement new. If the constructor for the object exits via an exception,
  47. >the compiler will call the corresponding placement delete automatically
  48. >as a special case.
  49. >    T* p = new (x) T;
  50. >The reasons for this special case are
  51. >1. You do not know what needs to be deleted in general, but the compiler
  52. >does.
  53. >2. The compiler has all the information it needs to invoke the special
  54. >operator delete() correctly. It is invoked at the point of the
  55. >new-expression.
  56.  
  57. >>but there is no matching version of 'delete'? Are we supposed to use both 
  58. >>destroy() and deallocate() to get rid of that object?
  59.  
  60. >Yes. In the above example:
  61. >    p->~T();
  62. >    operator delete(p, x);
  63.  
  64. How can you guarantee that the first argument to operator delete
  65. will be correct? It might be slightly safer to write:
  66.  
  67.     void* q = p;  // evaluate before destruction
  68.     p->~T();
  69.     operator delete(q,x);
  70.  
  71. and I am not sure if this is guaranteed to be safe.
  72.  
  73. One form for placement operator delete, that might avoid ambiguity is:
  74.  
  75. delete (placement parameters) (pointer)
  76.  
  77. The extra parentheses around the pointer would make this not a
  78. syntactically correct non-placement delete.
  79. -- 
  80. * IRS, IRS, lord of the federal tax, checking all income and every deduction,*
  81. * mailing out form 10 40, penalizing noncompliers, regulating, and auditing. *
  82. David Sachs - Fermilab, HPPC MS369 - P. O. Box 500 - Batavia, IL 60510
  83. Voice: 1 708 840 3942      Deparment Fax: 1 708 840 3785
  84. ---
  85. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  86.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  87.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  88.